This section is intended to give a summary of the major events of the requirements engineering project and the key experiences that shaped our overall project experience.\\\\
In the second week, when we were prioritizing the project missions written by the other groups, one of our core criteria was that the scope of the mission was not too narrow. We thought that choosing one of the more narrow projects would make it hard to come up with a good amount of requirements. Later on we found that it all depends on the level of detail and the commitment to the more “trivial” requirements. The requirements document for any of the projects stated in the project missions could be made arbitrarily long. We had chosen a project with a rather wide scope and also gone in to too much depth in some cases. This initially led to a quantity over quality situation with our requirements and also caused us to spend much more time on the project than we had originally planned.\\\\
Another event that greatly affected the rest of our work was our decision to change the project mission. During our analysis of the market we found out that the original application was not going to profitable due to there already being free applications with the same functionality available. Instead of just carrying on with writing requirements for the original idea, which is essentially what our contractors were “paying” us to do, we decided to contact them and propose some changes to the project mission. This also led to us spending additional time reworking our existing set of requirements and eliciting all the new ones. \\\\
Throughout the project we have had to spend too much time working our rather extensive requirements document. This has led to us to sometimes being too informal during interviews and it has also probably been a major reason of our rather lacking documentation of the usage of some techniques. 
